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PREFACE 


This  handbook  is  to  acquaint  small  businesses  with 
use  of  electronic  data  interchange  (EDI)  when  doing 
business  with  the  Department  of  Defense.  Of  course, 
most  of  these  same  principles  apply  when  using  EDI  to 
do  business  with  major  defense  contractors  or  with 
other  small  businesses. 


Both  business  and  DoD  readers  should  find  that  this 
handbook  provides  useful  information  on  the 
implementation  of  American  National  Standards 
Institute  (ANSI)  Accredited  Standards  Committee 
(ASC)  X12  EDI  standards  within  automated  data 
processing  systems. 
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CHAPTER  1 


INTRODUCTION  TO  ELECTRONIC  DATA 
INTERCHANGE 

DEFINITION 

Electronic  data  interchange  (EDI)  is  the  computer-to- 
computer  exchange  of  routine  business  information 
using  Accredited  Standards  Committee  (ASC)  X12 
standards.  EDI  is  now  in  common  use  in  many  private 
companies  and  promises  to  become  the  preferred 
method  for  conducting  all  business  in  the  future.  After 
acquiring  the  appropriate  computer  hardware,  soft¬ 
ware,  and  communications,  businesses  can  eliminate 
the  burden  of  paper  purchase  orders,  invoices,  ship¬ 
ping  forms,  and  other  documents  that  are  now  used  to 
conduct  business.  EDI  will  replace  them  with  their 
electronic  equivalents.  The  motivation  to  move  to  EDI 
is  compelling:  the  costs  for  processing  one  multipart 
paper  document  from  “cradle  to  grave”  typically  can 
range  from  $10  to  $40  and  sometimes  more.  Con¬ 
ducting  business  electronically  eliminates  these  paper 
forms  and  can  slash  these  costs  by  a  third  to  a  half. 
Other  benefits  are  identified  later. 

Certainly,  the  computer-to-computer  interchange  of 
information  is  not  new  to  American  industry  nor  to 
DoD.  Since  the  mid-1950s,  large,  private  companies 
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and  DoD  activities  have  been  sharing  business  infor¬ 
mation  electronically.  But,  because  users  communi¬ 
cated  in  unique  formats,  businesses  found  it 
cumbersome  and  time  consuming  to  expand  their 
electronic  communications  to  new  trading  partners. 

Today,  however,  nationally  and  internationally  recog¬ 
nized  data  formats,  commonly  referred  to  as  standards 
or  transaction  sets,  have  been  developed  to  allow  easy 
interchange  of  data.  Commercial  computer  programs 
eliminate  the  need  to  create  special  software  to  receive 
or  send  user-unique  data  formats.  Instead,  one  soft¬ 
ware  package  can  generate  standard  formats  to 
exchange  information  between  all  trading  partners. 
And,  interestingly,  many  companies  now  use  these 
same  standards  to  enable  exchange  of  information 
between  incompatible  software  and  hardware  within 
their  organizations. 


STANDARDS 


Two  key  groups  developed  the  EDI  standards  for  North 
America:  the  Transportation  Data  Coordinating  Com¬ 
mittee  (TDCC)  and  the  American  National  Standards 
Institute  (ANSI)  ASC  X12.  The  TDCC,  formed  in  the 
late  1960s,  initially  created  transportation  standards 
for  rail,  motor,  air,  and  ocean  shipping.  Its  success  led 
other  industry  groups  like  grocery,  chemical,  and 
warehousing  to  seek  its  help.  As  TDCC  created 
industry-oriented  standards,  some  companies  and 
individuals  saw  the  need  for  generic  standards  that  cut 
across  industry  boundaries. 
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In  1979,  ANSI  formed  the  ASC  X12  to  develop  uniform 
standards  for  electronically  interchanging  business 
transactions  between  and  among  industries.  What 
this  means  is  that  the  automotive  industry,  for 
example,  can  now  share  a  single  standard  to  exchange 
electronic  purchase  orders,  invoices,  and  technical 
specifications  with  the  chemical,  textile,  and  steel 
industries. 

The  TDCC  and  ASC  X12,  through  the  Joint  Electronic 
Data  Interchange  Committee,  created  and  published  a 
data  dictionary  that  provides  for  common  EDI 
standard  elements,  segments,  and  codes.  This  diction¬ 
ary  is  in  essence  a  common  set  of  definitions  and  terms 
for  creating  standard  EDI  transactions. 

CONFIGURATION  OPTIONS 

To  do  business  electronically,  you  need  three  types  of 
resources:  computer  hardware,  computer  software, 
and  communication  connections. 

Computer  Hardware 

Three  basic  sizes  of  computers  are  used  today: 
personal  computer  (PC),  minicomputer,  and 
mainframe. 

When  using  a  PC  to  process  data,  all  processing  is  done 
by  the  PC  one  job  at  a  time  using  EDI  software  (see 
Figure  1-1).  Once  the  PC  cor  ^.letes  processing,  it 
sends  the  transactions  to  its  trading  partner  or  trading 
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partner’s  network  using  communications  software  and 
dial-up  telephone  lines.  When  receiving  inbound 
transactions,  the  PC  obtains  transactions  from  its 
trading  partner  or  trading  partner’s  network  over  dial¬ 
up  telephone  lines  and  processes  them.  If  you  select  a 
PC,  the  start-up  costs  of  the  equipment  range  from 
$3,000  to  $4,000. 


FIG.  1-1.  STANDALONE  MICROCOMPUTER 

If  you  select  a  minicomputer,  the  same  sequence 
occurs,  only  the  minicomputer  can  process  multiple 
jobs.  If  the  minicomputer  is  used  as  a  front-end 
processor  to  a  mainframe,  the  minicom’'uter  will 
process  all  input  and  output  transactions  (see 
Figure  1-2).  When  the  front-end  minicomputer  com¬ 
pletes  its  job,  data  are  passed  to  the  mainframe 
computer  where  they  are  stored  for  other  business 
applications.  Start-up  costs  for  a  minicomputer  range 
from  $10,000  to  $15,000,  but  it  can  process  higher 
transaction  volumes. 

If  you  already  have  a  mainframe  computer  all  proces¬ 
sing  will  be  performed  within  the  mainframe  or 
its  communications  controllers/processors  (see 
Figure  1-3).  The  mainframe  receives/sends,  trans¬ 
lates,  and  processes  all  transactions.  These  data  reside 


in  files  or  data  bases  for  use  by  other  business 
applications. 


FIG.  1-2.  MAlNmAMC/MINlCOMHITEfl  FHOMT  END  ntOCfSSO# 
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FIG.  1-3.  MAINFRAME 


Computer  Software 

Computer  EDI  software  costs  range  from  a  few 
hundred  dollars  for  PCs  to  thousands  of  dollars  for 
mainframe  computers.  Some  large  businesses  may 
choose  to  develop  their  own  software.  This  approach  is 
not  recommended  for  the  novice  or  small  business. 

EDI  software  capabilities  range  from  allowing  users  to 
process  low-volume  transactions  on  a  PC  to  the  full 
range  of  capabilities  designed  to  run  on  a  mainframe. 
Some  EDI  software  allows  users  to  design  and 


5 


maintain  electronic  forms  that  replicate  paper 
business  forms  such  as  invoices,  purchase  orders,  and 
requests  for  quotes  (RFQ).  It  can  also  send/ receive, 
translate,  and  store  data  to  be  used  by  other  business 
applications.  Other  software  can  limit  access  and 
protect  corporate  data  with  passwords  and  encryption. 


Communications 

The  transaction  standards  and  the  method  of  com¬ 
municating  those  standards  are  two  primary  parts  of 
EDI.  A  possible  addition  is  special  security  proce¬ 
dures.  There  is  no  single  or  preferred  communication 
solution.  Each  company  must  determine  the  proper 
approach  based  on  current  and  projected  transaction 
volume,  level  of  service,  and  cost.  Two  alternatives  are 
possible:  point-to-point  and  value-added  network 
(VAN),  also  known  as  third-party  network. 

•  Point  to  point.  Direct  connection  between  trading 
partners  can  be  either  by  dedicated  line  or  through 
a  dial-up  network.  This  option  requires  close 
coordination  of  data  exchanges  between  trading 
partners  and  becomes  very  complex  as  the  number 
of  trading  partners  increases. 

•  VAN.  The  VAN  shown  in  Figure  1-4  provides  an 
electronic  mailbox  for  each  trading  partner.  One 
partner  can  send  data  to  another’s  mailbox  for  later 
pickup  and  also  pick  up  his  or  her  own  EDI  data 
without  having  to  connect  directly  to  the  other 
trading  partner.  This  option  reduces  the  coordina¬ 
tion  problem,  and,  for  this  reason,  a  VAN  is  useful 
for  large  businesses  as  well  as  small  businesses. 


6 


SwPP'**'  payment 

FIG.  1<4.  COMMUNICATIONS  USING  VALUE-ADDED  NETWORKS 


BUSINESS  PROCEDURE  INTEGRATION 

Streamlining  your  way  of  doing  business  is  where  EDI 
shows  its  real  value.  First,  look  at  your  paper  business 
systems  with  fresh  eyes.  The  most  effective  EDI 
system  is  not  one  that  simply  recreates  electronic 
versions  of  paper  forms.  A  good  system  will  change  the 
way  a  company  does  business  to  exploit  the  capabil¬ 
ities  of  EDI.  It  is  not  at  all  unreasonable  to  devise  a 
system  that  almost  eliminates  such  things  as  paper 
invoices,  multiple  copies  of  correspondence  (including 
electronic  copies,  of  course),  contract  files,  and  so  on. 
However,  the  path  from  here  to  there  is  not  the 
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automation  of  current  paper  trails.  The  key  to  success 
lies  in  intelligent  examination  of  current  business 
procedures.  Some  procedures  will  no  longer  be  needed. 
Redefine  procedures  so  they  can  be  enhanced  by  using 
the  computer.  More  importantly,  new  capabilities  will 
emerge  that  were  not  possible  in  the  past  world  of 
paper-based  transactions. 

EDI  BENEFITS  TO  THE  SMALL  BUSINESS 

The  benefits  of  EDI  to  the  small  business  extend  far 
beyond  a  decrease  in  paper  handling  and  storage. 
They  include  increased  business  opportunities,  more 
accurate  records,  lower  data  entry  costs,  lower  mailing 
costs,  greater  customer  satisfaction,  reduced  order 
time,  and  the  availability  of  more  accurate  informa¬ 
tion  to  support  decisions. 

Increased  Business  Opportunities 

Thousands  of  RFQs  for  small  purchases  that  were 
previously  only  found  on  the  bulletin  boards  outside 
the  Government  contracting  office  will  be  made 
available  to  you.  Also,  having  the  RFQs  in  an 
electronic  form  will  enable  you  to  rapidly  review, 
select,  and  respond  to  the  RFQs,  eliminating  days  of 
administrative  processing. 

More  Accurate  Records 

After  a  company  enters  data  by  keying  them  directly 
into  its  system,  the  software  edits  the  data  to  ensure 
accuracy.  For  example,  software  editing  will  display 
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an  error  message  if  the  account  number  or  part 
number  is  not  valid  or  if  the  price  is  incorrect.  When 
massive  amounts  of  data  are  exchanged  some  errors 
will  occur,  especially  if  data  are  entered  manually. 
Data  entry  errors  can  prove  to  be  very  costly.  An 
invoice  authorized  for  a  $1,000  payment  instead  of  a 
$100  payment  or  an  order  to  ship  100  items  instead  of 
10  items  can  be  costly.  When  errors  are  discovered, 
time  and  money  will  be  wasted  tracking  down  and 
correcting  them.  Even  if  98  percent  of  the  information 
entered  manually  is  accurate,  the  2  percent  that  is  not 
can  be  embarrassing  or  costly  if  a  customer’s  name  is 
misspelled  or  an  invoice  is  undercharged. 

By  exchanging  data  directly  between  computer 
systems  EDI  ensures  greater  information  accuracy.  A 
major  freight  carrier  indicated  that  one  EDI  client 
transmitted  600,000  freight  bills  electronically  in  a 
span  of  18  months  with  absolutely  no  errors.  For  that 
client,  the  elimination  of  errors  alone  paid  for  the  cost 
of  developing  its  EDI  system. 

Lower  Data  Entry  Costs 

Nothing  is  more  inefficient  than  manually  entering 
data  from  one  computer  printout  into  another 
computer  system.  EDI  eliminates  the  need  to  re-enter 
such  data.  With  most  communications  packages 
today,  information  can  be  transmitted  directly  from 
one  computer  to  another.  EDI  installations  report  that 
they  have  accurately  transmitted  10,000  invoices 
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within  minutes  and  processed  them  immediately 
without  human  intervention. 

Reduced  Inventory 

Timely  processing  of  information  allows  suppliers  to 
know  what  material  to  ship  and  when  to  ship  it  instead 
of  having  to  estimate  such  factors.  One  large  company 
reduced  its  inventory  by  $167  million  in  the  first 
18  months  after  it  implemented  EDI.  They  not  only 
saved  the  cost  of  carrying  inventory  but  were  also  able 
to  reduce  the  amount  of  warehouse  space  they  needed. 

Inventory  reductions  through  EDI  are  not  limited  to 
users;  suppliers,  too,  have  been  able  to  reduce  their 
inventories.  Suppliers  have  learned  to  trust  EDI  infor* 
mation  and  plan  receipt  of  material  and  production 
runs  based  on  true  need,  not  guesswork  or  urgent 
phone  calls. 

Decreased  Mailing  Costs  and  Paper  Handling 

Mailing  an  order  in  the  traditional  way  is  costly  and 
inefficient.  When  the  cost  of  typing  the  order, 
addressing  the  envelope,  and  inserting  the  order  into 
the  envelope  are  added  to  the  cost  of  postage,  a  single 
order  can  cost  $5  or  more.  When  many  orders  are  sent 
each  year,  costs  accumulate.  Sending  orders  as 
overnight  packages  adds  another  $5  to  $10.  Many 
operations  justified  EDI  by  the  savings  in  mailing  and 
handling  costs  alone. 
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When  transmitting  information  between  trading 
partners  (even  in  a  small  company)  the  mounds  of 
paper  previously  moved  from  one  department  to  the 
next  can  be  eliminated.  Information  stored  on  the 
computer  is  readily  accessible  by  the  order  entry, 
accounts  receivable,  and  other  departments  within  the 
company. 

Instead  of  using  people  handling  pieces  of  paper,  EDI 
via  computer  can  print  directly  onto  other  electronic 
media  and  maintain  a  copy  for  audit  record  purposes. 

Many  businesses  use  the  remittance/payment  advice 
to  electronically  apply  cash  to  an  account.  One  check 
may  pay  thousands  of  invoices.  To  post  such  payment 
information  manually  may  take  hours,  whereas  with 
EDI,  it  can  be  done  with  absolute  accuracy  in  minutes. 

Greater  Customer  Satisfaction 

With  an  efficient  EDI  system,  an  order  can  be  received, 
processed,  and  shipped  almost  as  quickly  as  it  can  be 
transmitted.  Companies  may  use  EDI  to  buy  office 
supplies,  furniture,  clothing,  and  other  items  not  used 
directly  in  their  production  processes.  They  send  the 
order  electronically  and  the  goods  are  shipped 
immediately.  Many  freight  carriers  provide  their 
customers  with  status  reports  about  their  shipments. 
Locating  shipments  more  quickly  and  efficiently  adds 
to  customer  satisfaction. 
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Reduction  in  Order  Time 


When  submitting  and  receiving  an  order  by  mail, 
postal  service  and  handling  time  can  consume  a  week 
or  more.  Allowing  for  1-day  handling  of  paper  on  both 
ends  plus  2  and  3  days  in  the  postal  system  means  that 
the  use  of  EDI  can  eliminate  almost  a  full  week  of 
order  time.  With  EDI,  in  many  cases  companies  can 
order  goods  and  have  them  shipped  the  same  day. 

Better  Cash  Management 

By  taking  advantage  of  EDI,  companies  can  ensure  the 
purchase  of  the  right  material  at  the  right  time.  Thus, 
they  are  better  able  to  plan  cash  disbursements.  When 
EDI  is  used  to  transmit  an  invoice  or  advanced 
shipping  notice  for  use  in  an  evaluated  receipt  settle¬ 
ment  (ERS)  system,  the  invoice  is  handled  with 
consistency,  and  no  guesswork  is  needed  to  know  when 
it  will  be  paid.  This  consistency  allows  for  much  more 
efficient  cash  management. 

With  the  added  use  of  electronic  funds  transfer  (EFT) 
and  EDI,  both  parties  can  better  plan  the  use  of  funds. 
A  paper  pa3mient  check  may  arrive  anywhere  from  2  to 
4  days  after  it  has  been  mailed.  (That  time  is  referred 
to  as  the  float.)  With  EFT,  the  money  arrives  on  a 
preplanned  date.  With  consistent  money  flow,  money 
use  can  be  planned  more  efficiently. 
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More  Accurate  Information  Available  to  Make 
Decisions 


The  availability  of  accurate  information  supplied  by 
EDI  permits  an  organization  to  identify  problem  areas 
more  quickly.  It  highlights  areas  with  the  greatest 
potential  for  efficiency  improvement  or  cost  reduction. 
Better  information  about  shipping  charges,  inven> 
tories,  sales  orders,  shipment  dates,  invoice  amounts, 
or  cash  flow  is  key  to  more  efficient  operation. 
Continuous  knowledge  of  the  location  of  inbound 
freight,  for  example,  enables  more  accurate  scheduling 
of  the  receiving  dock  and  in  many  cases  better 
scheduling  on  the  production  floor. 
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CHAPTER  2 

USING  EDI  TO  SELL  PRODUCTS 


USING  EDI  FOR  PROCUREMENTS 

The  DoD  uses  two  basic  categories  of  electronic 
purchases;  purchase  orders  issued  against  existing 
contracts  (indefinite  delivery  contracts)  and  individual 
competitive  purchases. 

Indefinite  Delivery  Contracts 

Multi-item,  indefinite  delivery  contracts  usually 
create  a  multiyear  business  relationship  with  a 
commercial  vendor,  which  is  an  ideal  environment  for 
EDI.  Figure  2-1  shows  the  logical  data  flow  when 
using  EDI  to  order  supplies  and  services  under  a 
multi-item  indefinite  delivery  contract.  The  numbers 
in  the  illustration  are  EDI  transaction  numbers.  DoD 
issues  a  purchase  order  (transaction  850)  to  buy 
material  from  an  existing  contract.  The  vendor 
returns  a  purchase  order  acknowledgment  (trans¬ 
action  855)  to  confirm  the  order.  When  the  material  is 
shipped,  the  vendor  sends  a  shipment  notice/manifest 
(transaction  856)  to  the  buyer  followed  by  an  invoice 
(transaction  810).  Upon  notice  of  receipt  (trans¬ 
action  861),  DoD  initiates  an  EFT  payment  and 
payment  order/remittance  advice  (transaction  820). 
The  DoD  and  the  vendor  exchange  functional 
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acknowledgments  (transaction  997)  for  each  trans 
mission  to  confirm  that  the  format  of  the  trans 
missions  was  ANSI  X12  correct. 


Matm'  ACH  =  Automated  Clearing  House;  EFT  =  electronic  funds  transfer;  FMS  =  Financial  Management 
Service. 


FIG.  2-1.  INDEFINITE  DELIVERY  CONTRACT 
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Individual  Competitive  Purchases 


Common  items  whose  specifications  are  well  known  to 
both  DoD  and  vendors  can  be  purchased  using  EDI, 
although  this  is  a  more  complex  process.  Figure  2-2 
depicts  the  logical  data  flow  where  there  is  no  contract. 


FIG.  2-2.  INDIVIDUAL  PURCHASES 
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DoD  sends  an  RFQ  (transaction  840)  to  one  or  more 
vendors.  The  vendors  respond  with  a  quote  (trans¬ 
action  843).  DoD  then  sends  a  purchase  order  (trans¬ 
action  850)  to  the  vendor  of  choice.  The  vendor  sends 
acknowledgment  to  confirm  acceptance  (trans¬ 
action  855).  After  shipment,  the  vendor  sends  a  ship¬ 
ment  notice  (transaction  856)  to  DoD  followed  by  an 
invoice  (transaction  810).  Upon  notice  of  receipt 
(transaction  861),  DoD  initiates  an  EFT  payment  and 
payment  order/remittance  advice  (transaction  820). 
DoD  and  the  vendor  exchange  functional  acknowledg¬ 
ments  (transaction  997)  for  each  transmission  to  verify 
that  the  format  of  the  transmissions  was  ANSI  XI 2 
correct. 

SMALL-DOLLAR  PROCUREMENTS 

One  of  the  more  costly  aspects  of  DoD  procurement  is 
competitive  small-dollar  procurement.  It  has  been 
estimated  that  the  process  of  making  a  single  pur^^hase 
of  an  item  priced  under  $25,000  can  cost  anywhere 
from  $50  to  $250  or  more  in  direct  and  indirect  costs. 
Using  electronic  commerce  (EC)/EDI  techniques  can 
reduce  costs,  while  still  meeting  the  following  basic 
procurement  requirements: 

•  New  RFQs  are  announced  promptly. 

•  Even  competition  is  promoted,  in  accordance  with 
Federal  Acquisition  Regulation  (FAR)  13-106. 

•  A  lower  cost  than  current  paper-based  and 
telephone-based  systems  is  achievable. 
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•  The  integrity  and  confidentiality  of  submitted 
quotes  is  ensured. 

•  Award  information  is  provided  to  appropriate 
respondents. 

•  Electronic  mail  (E-mail)  is  integrated  between 
suppliers  and  DoD. 


The  DoD  EDI  integration  plan  uses  E-mail  as  the 
carrier  of  information  ensuring  confidentiality  of 
respondents.  The  series  of  events  would  follow  a 
sequence  similar  to  the  following: 


•  DoD  contracting  and  procurement  offices  provide 
ANSI  X12  RFQs  to  a  DoD  host  computer. 

•  DoD  host  computer  disseminates  information  to 
participating  commercial  VANs. 

•  VANs,  on  receipt  of  the  information,  make  the 
information  available  to  private-industry  sup¬ 
pliers/subscribers  for  standard  fees.  (Using  a  VAN 
as  a  vehicle  for  communicating  with  business 
trading  partners  is  the  configuration  that  has  been 
most  preferred  by  small  companies.) 

•  Commercial  subscribers  respond  to  an  RFQ  and 
submit  quotes  using  ANSI  X12  standards. 

•  VANs  receive  quotes  and  responses  from  private- 
industry  subscribers  and  forward  them  directly  to 
the  DoD  host  computer. 

•  DoD  host  computer  time-stamps  messages  and 
archives  them  for  audit.  The  system  simultane¬ 
ously  forwards  the  original  bid  messages  to  the 
contracting  officers. 
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•  DoD  awards  the  contract  after  an  appropriate 
evaluation  period.  It  sends  the  contract  information 
via  the  same  channels  to  the  awardee.  DoD  also 
provides  the  award  information  to  participating 
VANs  for  posting  on  their  electronic  bulletin  boards 
to  make  it  accessible  to  its  subscribers. 

•  EDI  transactions  which  were  a  part  of  this  entire 
process  now  join  with  the  rest  of  the  purchasing 
process,  culminating  in  the  payment  of  an  invoice 
(which  was  also  received  electronically)  using  EFT. 


This  system  has  a  numbe-  of  fe  itures  which  should  be 
emphasized,  including  the  following: 


•  One-time  registration  for  vendors  across  DoD’s  sites 
for  most  purchases  using  a  simple  electronic 
process. 

•  Appropriate  secure  mail  procedures,  password 
protected  or  encrypted,  will  be  used  by  both  the 
individual  supplier  and  the  DoD  contracting  officer. 

•  Small  businesses  can  choose  to  use  the  VAN  which 
provides  the  best  price/performance  combination  for 
them.  This  encourages  competition  among  VANs. 

•  DoD  personnel  will  archive  quote  data  to  provide  an 
audit  trail. 

•  E-mail  and  query-by-mail  techniques  eliminate  the 
requirement  for  having  thousands  of  simultaneous 
logins  on  a  DoD  or  commercial  VAN  computer. 


•  Quote  information  is  stored  on  a  DoD  computer, 
Ahich  can  make  powerful  statistical  analyses  of 
data. 

•  RFQ  information  is  stored  in  the  DoD  host 
computer,  and  lists  of  quotes  can  be  pinpointed  for 
local  minority  or  depressed  area  initiatives. 

USING  EDI  AND  ELECTRONIC  FUNDS  TRANSFER 

The  contractor  must  use  the  Standard  Form  3881 
Payment  Information  Form  to  request  that  the  DoD 
agency  pay  using  direct  deposit.  After  approval  and 
testing,  payment  data  are  transmitted  to  the  Federal 
Reserve  Bank  (FRB)  to  initiate  direct  deposit 
payments  to  the  contractor’s  bank  account.  The 
electronic  payment  conforming  to  National  Automated 
Clearing  House  Association  rules  includes  addenda 
records  as  well  as  the  disbursement  amount.  The 
addenda  records  use  ANSI  X12  standards  to  define  the 
structure  of  the  remittance  information. 

By  combining  the  payment  with  the  EDI  payment 
information,  the  contractor  can  credit  the  payment 
upon  notice  of  the  deposit  and  save  reconciliation  time. 
Reports  are  generated  to  provide  an  appropriate  audit 
trail  and  to  establish  a  complete  history  of 
disbursements. 
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CHAPTER  3 

PLANNING  EDI  FOR  SMALL  BUSINESS 

DEFINITION 


To  avoid  misunderstanding  about  the  meaning  of  the 
term  “small  business,”  we  use  the  Small  Business 
Administration  (SBA)  definition.  A  small  business  is 
one  that  is  independently  owned  and  operated  and  not 
dominant  in  its  field.  The  following  size  and  volume 
standards  are  used  to  determine  eligibility  for  some 
SBA  programs;  they  illustrate  that  small  business 
does  not  always  mean  small. 

•  Manufacturing  —  fewer  than  500  employees 

•  Wholesale  —  fewer  than  100  employees 

•  Retail  —  less  than  $3.5  million  in  sales  per  year 

•  Service  ~  less  than  $3.5  million  in  sales  per  year 

•  Construction  —  less  than  $17  million  in  sales  per 
year. 

GETTING  STARTED  IN  EDI 

The  first  step  is  to  review  the  standards  and  internal 
systems  of  a  small  business.  Can  ANSI  standards  be 
met?  Each  ANSI  standard  is  introduced  with  the 
following  words:  “This  standard  was  developed  with 
the  intent  that  users  need  not  reprogram  their 
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internal  data  processing  systems.”  The  ANSI 
standard  is  structured  to  allow  computer  programs  to 
translate  internal  formats  to  the  ANSI  XI 2  standard, 
and  conversely.  Software  to  translate  data  to  and  from 
the  ANSI  standard  format  may  be  developed  by  the 
small  business  or  purchased  commercially.  Most  small 
businesses  elect  to  purchase  commercially  available 
translation  software. 

If  you  are  processing  information  on  paper  today,  you 
can  convert  to  EDI.  You  will  discover  that  some 
efficiencies  can  be  realized  if  the  internal  data  flow  is 
changed,  but  you  do  not  have  to  change  it  to  conduct 
business  electronically.  You  may  also  consider  some 
or  all  of  the  steps  outlined  below. 


Education 


Both  Grovernment  and  commercial  EDI  seminars  can 
expose  you  to  what  others  are  doing  and  help  you  sell 
the  idea  of  EDI  to  your  company.  EDI  educational 
seminars  are  sponsored  by  many  sources:  the  Federal 
Government’s  “Productivity  Enhancement  Program,” 
the  Automotive  Industry  Action  Group,  the  National 
Industrial  Transportation  League,  the  American 
Trucking  Association,  the  Electronic  Data  Inter¬ 
change  Association  (EDIA),  ASC  X12  Data  Inter¬ 
change  Standards  Association  (DISA),  and  some 
VANs. 
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Establish  a  Project  Team 


The  team  approach  to  EDI  has  proven  to  be  highly 
successful.  Some  EDI  projects  may  invol/e  only 
selected  departments,  but  others  will  cross  several 
departments.  All  company  departments  need  to  be 
represented  on  the  EDI  team.  Select  a  project  leader  to 
help  coordinate  meetings  and  EDI  projects.  Share  the 
information  about  these  meetings  by  distributing  the 
minutes  to  as  many  people  as  possible.  They  will  help 
others  in  your  company  learn  what  you  are  doing. 

Discuss  the  various  aspects  of  EDI  at  your  project  team 
meetings.  What  types  of  EDI  transactions  do  you  want 
to  do?  What  standards  could  you  use?  Would  a  third- 
party  network  help?  What  resources  do  you  need? 
What  standards  are  already  being  used  in  your 
company  or  industry? 

Use  these  meetings  to  help  educate  your  organization 
on  EDI.  Bring  in  outside  experts,  such  as  the  Federal 
agency  or  company  with  which  you  plan  to  become  an 
EDI  trading  partner.  Gather  the  facts  and  communi¬ 
cate  the  results. 

Involve  your  financial  people  as  early  as  possible. 
Once  they  are  tuned  in  to  EDI,  they  may  become  your 
strongest  supporters. 
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Analyze  the  Company  System 


Carefully  consider  the  resources  that  you  will  need. 
Analysis  should  provide  answers  to  the  following 
questions: 

•  What  documents  will  be  sent?  What  ANSI  ASC 
XI 2  standard  will  be  used? 

•  Should  the  company  develop  its  own  communica¬ 
tions  network  or  select  a  third-party  network? 

•  Should  the  company  purchase  software  or  write  its 
own? 

•  When  will  resources  be  available? 

All  EDI  systems  incur  some  communications  costs. 
These  costs  are  assumed  by  different  parties  that  vary 
from  industry  to  industry  and  company  to  company. 
When  compared  with  the  overall  savings  produced  by 
EDI,  these  costs  often  are  insignificant.  In  some 
industries,  the  supplier  typically  pays  for  the  phone 
charges  or  third-party  network  charges  for  sending 
and  receiving  EDI.  In  other  industries,  the  sender  of  a 
message  may  pay  the  costs  or  the  sender  and  receiver 
may  split  them  evenly.  Review  the  practice  your 
trading  partner  follows  and  establish  an 
organizational  position  for  your  company. 

Develop  a  Plan 

A  strategy  should  evolve  from  these  discussions.  Each 
department  should  submit  a  summary  of  projects  to 
which  EDI  can  be  applied:  systems,  accounting. 
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auditing,  legal,  and  transportation.  These  projects 
should  be  included  in  the  company  budget.  If  a  project 
would  not  provide  a  payback,  re-evaluate  it.  EDI  must 
be  applied  for  good  business  reasons,  not  just  for  the 
sake  of  applying  EDI. 

If  the  appropriate  information  can  be  printed  on  a 
piece  of  paper,  it  can  also  be  translated  for  EDI.  But 
when  starting  out,  do  not  try  to  make  too  many 
changes  at  once. 


If  a  piece  of  information  does  not  translate  easily,  do 
not  immediately  revise  your  system.  Perhaps  a  note 
(NTE)  segment  of  an  EDI  transaction  will  get  you  by 
until  sufficient  business  reasons  require  that  the 
internal  programs  be  updated.  Refer  to  your  industry 
or  trading  partner’s  guidelines  for  assistance.  If  the 
existing  codes  do  not  match  your  circumstances, 
submit  a  change  request  to  the  ASC  X12  Data 
Interchange  Standards  Association. 

Reach  consensus  on  the  long-term  goals  and  establish 
individual  tasks  that  move  toward  those  goals.  Assign 
responsibilities  to  individuals  to  complete  these  tasks. 
To  keep  the  team  motivated,  it  needs  success.  Publish 
results.  The  more  the  entire  organization  knows  about 
the  successes,  the  more  others  will  give  their  support. 

Choose  a  Trading  Partner 

The  trading  partner  chosen  for  a  pilot  test  in  most 
cases  will  be  a  Defense  agency.  If  not,  select  a 
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company  that  already  has  EDI  experience.  A  supplier 
or  customer  may  have  already  expressed  interest  in 
doing  business  using  EDI. 

The  pilot  test  will  reveal  the  processes,  procedures, 
and  operations  that  need  to  be  v/orked  out.  The  more 
your  trading  partners  know  about  your  company  plans 
the  happier  they  will  be  about  using  EDI  with  your 
company.  Give  your  trading  partners  at  least  60  to  90 
days’  notice  of  your  pilot  test.  They  will  need  to  make 
some  evaluations  to  help  you  start  your  EDI  project. 

The  trading  partners  that  send  you  the  largest  number 
of  RFQs  are  the  ones  that  will  gain  the  most  from  your 
EDI  system.  Choose  such  a  company  for  your  test.  The 
one  that  sells  you  the  largest  number  of  individual 
items  is  the  one  that  will  gain  the  most  from  an 
electronic  material  release  or  schedule. 


CHAPTER  4 


IMPLEMENTATION  OF  EDI 
IN  A  SMALL  BUSINESS 


After  following  the  planning  prescription  of  Chapter  3, 
you  should  be  ready  to  implemer  t  fiDI.  If  you  are 
installing  EDI  and  currently  use  an  automated  data 
processing  system,  you  will  essentially  apply  the 
ANSI  Xl2  standard  to  your  current  system.  If  you  are 
starting  with  a  paper-based  system,  you  may  want  to 
install  additional  automation  capability  in  conjunction 
with  your  EDI  system. 

Implementing  EDI  is  not  an  insignificant  task.  It  is 
intended  to  change  the  way  you  do  business.  Top 
management  must  be  involved  in  the  approval  phases 
of  the  project  to  ensure  the  availability  of  adequate 
funding  and  personnel.  Requirements  for  projects  will 
vary  from  one  organization  to  another,  but  the 
company  should  adhere  to  the  following  general  rules 
for  a  successful  project: 

•  Treat  EDI  as  a  business  issue  because  EDI  is  a 
solution  to  a  business  problem. 

•  Do  not  deviate  from  the  ANSI  X12  standards. 
Deviations  will  require  that  the  system  be 
customized,  which  will  increase  costs  in  the  long 
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run.  Deviations  will  cause  problems  for  you  and 
your  trading  partners  when  the  ANSI  X12 
standards  change. 

•  Make  the  transition  to  a  full  production  system  only 
after  your  system  has  proved  itself  in  testing. 


EDI  STAFF 


Traditional  internal  automation  projects  differ  from 
EDI  projects  in  that  planning,  development,  and 
implementation  tasks  must  be  performed  in  concert 
with  the  trading  partners. 

Implementing  an  EDI  project  will  involve  several 
people  in  a  variety  of  roles.  At  a  minimum,  the  EDI 
project  should  have  the  following  staff: 

•  Senior  manager 

•  Functional  coordinator 

•  EDI  coordinator 

•  Contract  administrator. 

For  a  small  business,  some  of  these  positions  will  be 
combined.  (For  larger  systems,  more  personnel  may  be 
required.) 
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During  project  development,  it  will  be  necessary  to 
provide  ad  hoc  support  to  the  project  team.  The 
following  support  is  needed: 

•  Functional  managers  to  develop  the  business  plan 

•  Technical  and  functional  managers  to  coordinate 
standards  and  procedures  with  your  trading  partner 

•  Analysts  with  detailed  knowledge  of  the  interfacing 
systems,  communications,  computer  operations, 
and  operating  system  software. 


For  a  small  business,  this  support  can  be  combined 

into  a  small  group. 

IMPLEMENTATION  CHECKLIST 

•  Identify  key  management  the  personnel  from  each 
functional  area  affected  by  adoption  of  EDI.  Each 
area  should  be  included  in  analysis,  development, 
testing,  and  implementation. 

•  Provide  resource  estimates  and  identify  potential 
savings. 

•  Prepare  a  milestone  schedule  and  estimated 
completion  times. 

•  Contact  your  DoD  trading  partner  for  help  in 
implementing  the  ANSI  X12  standard.  Establish 
EDI  contacts  among  industry  associations  and 
network  providers. 

•  Obtain  copies  of  the  ANSI  X12  publications, 
training  materials,  and  implementation  guidelines. 
You  will  need  access  to  data  dictionaries  and 
documents  that  define  functional  codes.  Contact 
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DoD  or  industry  procurement  personnel  for  this 
documentation. 

•  Learn  the  types  of  resources  available  and  the 
communication  system  used  by  your  trading 
partner.  Your  system  must  be  compatible. 

•  Compare  your  business  data  against  your  trading 
partner’s  ANSI  X12  conventions.  This  will  help  you 
determine  whether  your  internal  system  contains 
the  required  data  elements.  You  should  identify 
optional  data  elements  and  discuss  them  with  your 
trading  partner. 

SYSTEM  INTEGRATION  PLAN 


Using  the  information  you  have  collected,  prepare  a 
detailed  system  integration  plan  that  may  include  the 
following  items: 

•  General  narrative 

•  Functional  description 

•  Data  requirements  and  data  flows 

•  Communications  network 

•  System  specifications 

•  Program  specifications 

•  User  procedures 

•  Computer  operations  procedures. 
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Develop  this  plan  early  since  it  will  influence  such 
other  decisions  as  maintaining  connections,  coordi¬ 
nating  the  polling  schedules,  providing  audit  reports, 


and  sharing  costs.  If  you  work  closely  with  your 
trading  partner,  your  plan  will  be  similar  to  his. 


COMMUNICATIONS  PLAN 

If  your  first  trading  partner  is  DoD,  you  must  find  out 
if  a  Grovernment  communications  network  is  available 
for  you  to  use.  If  none  are  available,  you  should 
investigate  third-party,  VAN  resources.  If  you  plan  to 
conduct  EDI  with  both  DoD  and  commercial  firms,  the 
VAN  is  your  best  choice. 

No  matter  which  communications  alternative  you 
choose,  some  hardware  or  software  installation  will  be 
required.  Installation  on  a  PC  is  the  least  complicated. 
Larger  computers  are  more  complicated.  Communica¬ 
tions  software  vendors  normally  provide  some 
installation  services.  Make  them  aware  of  your  needs 
by  providing  all  the  planning  information  you  have 
collected. 


Protocols 


A  protocol  is  a  kind  of  etiquette,  much  like  the 
conventions  people  follow  when  making  introductions, 
extending  greetings,  in  conversation,  and  parting. 
Computers  must  do  the  same  if  they  are  to  exchange 
information  with  one  another.  They  must  agree  to 
speak  the  same  language,  at  the  same  speed.  They 
should  know  how  to  say  hello  and  goodbye  to  each 
other.  They  have  to  agree  that  only  one  of  them  can 
speak  at  a  time.  The  rules  are  of  little  importance,  as 
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long  as  the  two  parties  can  agree  upon  and  follow 
them.  Such  a  set  of  rules  is  called  a  protocol. 

There  are  many  communications  protocols.  Their 
rules  are  designed  to  ensure  that  computer  files  (e.g., 
EDI  messages)  can  be  transferred  from  one  computer 
to  another  correctly  and  completely,  despite  the  many 
pitfalls  that  lie  in  the  way.  Some  typical  file  transfer 
protocols  are  XMODEM,  KERMIT,  and  YMODEM. 
Successful  file  transfer  requires  compatible  software 
running  on  the  two  machines  (or  compatibility  with 
your  VAN). 

Since  you  are  just  starting  EDI,  you  will  want  to 
adhere  to  the  protocol  that  your  trading  partner  or 
VAN  is  using.  If  you  plan  to  directly  communicate 
with  multiple  trading  partners,  you  may  have  to  use 
several  different  protocols.  This  is  one  area  where 
using  a  VAN  is  helpful.  The  VAN  can  make  the 
problem  of  multiple  protocols  transparent  to  you. 

Translation  Software 

Translation  software  is  a  set  of  programs  designed  to 
automatically  translate  proprietary  data  formats  into 
ASC  X12  standard  format  for  sending.  The  software 
reverses  the  process  when  data  are  received.  The 
ASC  X12  standard  normalizes  the  results  of 
processing.  It  does  not  affect  how  a  program  is 
designed  nor  how  it  operates. 
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Configuration  of  the  EDI  translation  software  depends 
on  how  your  system  is  designed.  For  all  but  in-house- 
developed  software,  translation  software  must  inter¬ 
face  with  your  internal  software  and  communication 
systems. 

Translation  software  must  be  configured  to  run  in  your 
system  environment  (unless  you  are  using  a  network- 
based  translation).  Tables  must  be  updated  and 
modified  to  support  your  applications. 

Choosing  EDI  Software 

Selecting  the  correct  EDI  software  to  meet  your 
particular  company  needs  makes  a  big  difference  in 
the  ease  and  timeliness  of  your  EDI  implementation. 
Good  EDI  software  vendors  are  a  source  of 
implementation  expertise  because  they  have  gone 
through  this  process  with  other  companies.  They  can 
help  you  with  all  of  the  choices  facing  you  as  you 
implement  EDI,  from  choosing  a  VAN  to  choosing  the 
hardware  components  required  to  do  the  job.  While 
there  are  many  good  software  packages  to  choose  from, 
EDI  software  falls  into  three  main  categories; 

•  Standalone  PC.  This  type  of  software  provides  data 
entry  screens  for  your  documents  as  well  as  printing 
commands.  The  software  performs  translation  to 
X12  standards  and  handles  communication 
interfaces  to  the  VANs  and  trading  partners. 

This  type  of  software  is  straightforward  to 
implement  and  can  get  you  started  in  EDI  quickly. 
Its  drawback  is  the  lack  of  integration  with  your 
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existing  application  software  (e.g.,  your  purchase 
ordering  system  or  accounts  receivable  system). 
You  will  have  to  re-enter  information  that  already 
exists  on  your  omputer. 

Standalone  PC  software  can  also  cost  less  than 
other  types.  Beware,  however,  of  per-document 
pricing  structures  rather  than  a  more  all-inclusive 
approach  —  you  may  end  up  paying  more  in  the  end 
as  your  EDI  usage  expands. 

To  summarize  —  standalone  PC  advantages  include 
quick  implementation  and  potential  low  cost.  A 
disadvantage  is  the  lack  of  integration,  forcing  re¬ 
entry  of  data. 

Integrated  PC/UNIX.  Integrated  software  has  the 
same  translation  and  communication  interfaces  as 
standalone  PC  software  and  also  includes  the 
ability  to  integrate  with  your  existing  application 
software,  eliminating  the  need  for  re-entry  of  data. 
This  type  of  software  usually  runs  in  both  the  PC 
and  UNIX  operating  system  environments. 

Integration  is  accomplished  in  two  very  different 
ways.  The  first  is  through  “flat  file  input,”  and  the 
second  is  through  “mapping.” 

Flat  file  input  integration  means  that  the  EDI 
software  will  accept  information  from  your 
application  software,  provided  that  you  can  first 
transfer  it  to  a  file  that  meets  the  format  criteria  of 
the  EDI  software.  This  may  or  may  not  be  possible 
for  your  particular  application  software.  It  may 
take  a  little  programming  expertise  on  your  part. 
Future  changes  by  your  trading  partners  may  also 
be  difficult  to  implement  quickly. 

Mapping  integration  allows  you  to  specify  a  link 
between  the  document  you  need  to  send  your 
trading  partner  and  the  data  layout  of  your 
application  software.  Once  the  link  is  set  up,  the 


data  exchange  is  automatic.  Future  changes  by 
your  trading  partners  can  be  implemented  easily, 
and  existing  “maps*’  can  be  copied  and  altered  to 
support  new  EDI  documents. 

Mapping  integration  is  the  more  desirable  of  the 
two  methods.  When  choosing  mapping  software, 
pay  close  attention  to  the  user  interface  and  ease-of- 
use  features  for  creating  the  maps  themselves. 

To  summarize  —  integrated  software  eliminates  the 
task  of  re-entering  data  but  at  a  higher  initial  cost 
than  standalone  PC  software.  Mapping-style 
integration  is  the  most  desirable. 

•  EDI  server/gateway.  If  you  want  to  support  business 
applications  on  one  or  more  mainframe  computers 
or  implement  advanced  EDI  you  need  to  use  EDI 
server/gateway  software.  This  software  has  all  of 
the  features  of  integrated  EDI  software  plus  data 
transfer,  routing,  and  timing  mechanisms; 
mailboxing  capabilities;  and  restart/  recovery 
options. 

Traditionally,  EDI  server/gateway  software  was 
run  on  the  mainframe.  With  the  advent  of 
powerful  minicomputers,  companies  can  choose  a 
minicomputer-based  server.  A  single  server  can 
interface  to  multiple  mainframe  host  machines. 

EDI  server/gateway  software  requires  a  longer 
implementation  timeframe  as  well  as  more  in-house 
computer  expertise  and  is  more  expensive  than 
either  standalone  PC  software  or  integrated 
software. 
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When  choosing  any  software  that  will  affect  your 
business  operations,  be  sure  to  do  the  following  when 
evaluating  the  software  vendors: 


•  Get  references  from  the  software  vendor.  Ask  for 
the  names  of  companies  similar  to  yours  who  used 
the  vendor’s  software  to  implement  EDI, 

•  Call  two  or  three  of  the  references  and  listen  to  their 
experiences  from  purchase  through  ongoing 
software  support. 

•  Take  a  copy  of  the  software  to  your  company  for  a 
test  or  trial  evaluation  if  possible. 

•  Attend  the  training  that  the  vendor  offers  so  you 
can  take  full  advantage  of  its  capabilities,  after  you 
choose  your  software. 


Good  software  from  a  reputable  vendor,  backed  up 
with  competent  support,  can  make  your  EDI  imple¬ 
mentation  a  profitable  decision. 


Table  4-1  identifies  functions  and  features  that  we 
recommend  for  inclusion  in  an  EDI  system. 


TABLE  4-1 


EDI  SYSTEM  SOFTWARE  REQUIREMENTS 


Operating  environment 

Function/feature 

Stand¬ 
alone  PC 

Front-end 
EDI  server/ 
gateway 

Minicomputer/ 

mainframe 

Ginimunications  features 

Communications  software 

M 

M 

M 

Transaction  set  consolidation  routines 

M 

M 

M 

Muitipie  communications  interface 

0 

0 

0 

Network  identification  table 

M 

M 

M 

Unattended  operations  capability 

M 

M 

M 

System  utilities 

Automatic  recovery/restart  capability 

M 

M 

M 

installation  routines 

M 

M 

0 

System  interface  routines 

Application  system  interface 

M 

M 

M 

Data  input  screens 

M 

0 

0 

Input  editing 

M 

0 

0 

User-defined  print  output 

M 

O 

O 

User-definable  system  interface 

0 

0 

0 

User-defined  data  input  saeens 

0 

0 

0 

Customized  operations  routines 

Code  conversion  capability 

0 

0 

O 

Data  element  delimiter  table 

M 

M 

M 

Functional  acknowledgment  capability 

M 

M 

M 

Multiple  header  support 

M 

VI 

M 

Segment  terminator  table 

M 

M 

M 

Notts:  M  =  mandatory;  0=optional. 

*  Only  pertinent  to  those  sites  that  will  use  point-to-point  communications  for  one  or  more  trading  partners. 
**  Operating  system  utilities  separate  from  the  translation  software  package  may  fulfill  this  requirement. 

‘  Either  training  or  the  help  saeens  and  tutorial  package  are  mandatory. 

When  the  requirements  for  such  a  feature  have  been  fully  defined,  we  expect  this  feature  to  be  mandatory 
for  all  operating  environments. 
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TABLE  4>1 


EDI  SYSTEM  SOFTWARE  REQUIREMENTS  (G>ntinued) 


Operating  environment 

Function/feature 

Stand¬ 
alone  PC 

Front-end 
EDI  server/ 
gateway 

Minicomputer/ 

mainframe 

Customized  operations  routines  (cont.) 
Trading  partner  {N'ofile 

0 

M 

M 

Transaction  set  sequential  numbering 

M 

M 

M 

Version  support  table 

M 

M 

M 

Editing  features 

Character  conversion  capability* 

0 

0 

0 

Inbound  standards  compliance  editing 

M 

M 

M 

Internal  codes  duplication  routine 

M 

0 

0 

Outbound  standards  compliance  editing 

M 

M 

M 

Transaction  set  correction  capability 

M 

0 

0 

System  maintenance  routines 

Automated  purging 

M 

M 

Mb 

Expandability 

M 

M 

M 

Maintenance  support 

M 

M 

M 

Table-driven  software  structure 

M 

M 

M 

Transaction  set  archiving^ 

M 

M 

M 

Venion  support 

M 

M 

M 

Report  functions 

Error  reports 

M 

M 

M 

Functional  acknowledgment  reconciliation 

M 

M 

M 

Moms:  M = mandatory;  0=optioruil. 

•  Only  pertinent  to  those  sites  that  will  use  point-to-point  communications  for  one  or  more  trading 
partners. 

Operating  system  utilities  separate  from  the  translation  software  package  may  fulfill  this  requirement. 

<  Either  training  or  the  help  screens  and  tutorial  package  are  mandatory. 

‘‘When  the  requirements  for  such  a  feature  have  been  fully  defined,  we  expect  this  feature  to  be 
mandatory  for  all  operating  environments. 
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TABLE  4*1 


EDI  SYSTEM  SOFTWARE  REQUIREMENTS  (Continued) 


Operating  environment 

Function/fcature 

Stand¬ 
alone  PC 

Front-end 
EDI  server/ 
gateway 

Minicomputer/ 

mainframe 

Report  functions  (cont.) 

Inbound  transaction  set  reporting 

M 

M 

M 

Outbound  transaction  set  reporting 

M 

M 

M 

Transmitted  characters 

0 

0 

0 

User-defined  management  reports 

0 

0 

O 

Support  features 

Helpsaeensc 

0 

O 

0 

Technical  documentation 

M 

M 

M 

Trainingc 

M 

M 

M 

Tutorial  package^ 

0 

0 

0 

User  documentation 

M 

M 

M 

User  support  (hot  lines) 

M 

M 

M 

Miscellaneous  features 

Compatibility  with  encryption  and 

authentication  package^ 

O 

0 

0 

Multiple  users 

0 

0 

0 

Selective  accessibility 

M 

M 

0 

System  entry  security 

M 

M 

0 

Moms:  M = mandatory;  0= optional. 

*  Only  partinant  to  thosa  titas  that  will  usa  point-to-point  communications  for  one  or  more  trading 
partners. 

^  Operating  system  utilities  separata  from  the  trarulation  software  package  may  fulfill  this  requirement, 
r  Either  training  or  the  help  Kreens  and  tutorial  package  are  mandatory. 

<*When  the  requirements  for  such  a  feature  have  been  fully  defined,  we  expect  this  feature  to  be 
mandatory  for  ail  operating  environments. 
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INTEGRATED  TESTING 


Conduct  an  integrated  test  of  all  components  to  verify 
that  the  system  can  perform  the  following  tasks: 

•  Obtain  data  from  your  internal  system 

•  Translate  those  data  to  ASC  X12  format 

•  Assemble  and  transmit  the  ASC  XI 2  formatted 
data  to  your  trading  partner 

•  Receive  transmissions  from  your  trading  partner 

•  Translate  the  ANSIX12  formatted  data  to  your 
internal  system  format 

•  Generate  and  send  an  acknowledgment. 

Conduct  extensive  system  testing  before  actual 
production.  Use  the  old  paper  system  in  parallel  to 
validate  your  new  design.  Schedule  these  tests  over  a 
predetermined  time  period.  Prepare  a  trading  partner 
agreement  (TPA)  document  to  be  signed  by  all 
participants  in  the  project  before  production  begins. 
Make  sure  everyone  signs  the  agreement. 


Initial  production  should  be  limited  to  one  trading 
partner.  Start  with  one  or  two  transaction  sets.  You 
should  determine  in  advance  a  specific  time  period  for 
the  initial  operational  capability  (IOC).  Use  that  time 
to  validate  assumptions  about  costs,  savings,  and 
transaction  processing  times.  Make  all  adjustments 
before  going  operational. 
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TRADING  PARTNER  AGREEMENTS 


Sometimes  referred  to  as  “preauthorization  agree¬ 
ments”  in  DoD,  TP  As  may  require  help  from  legal 
counsel.  Check  to  determine  if  DoD  has  a  general  TPA 
that  establishes  the  terms  and  conditions  for  EC.  If 
this  is  acceptable  to  you,  then  a  specific  TPA  will  not 
be  required.  Whether  it  is  a  stand-alone  agreement  or 
simply  a  provision  in  a  master  agreement,  a  TPA  must 
be  executed  before  you  begin  trading  using  EDI 
transaction  sets. 


The  TPA  is  the  key  document  that  sets  forth  the  rights 
and  obligations  of  the  trading  parties.  The  TPA 
provisions  are  tailored  by  DoD  to  meet  the  standard 
practice  of  the  industry  —  transportation,  medical 
supplies,  grocery,  etc.  The  following  elements  are 
essential  components  of  any  DoD  TPA.  (These 
elements,  of  course,  can  be  used  in  a  commercial  TPA 
as  well.) 


•  Recital.  A  statement  that  the  parties  desire  to  enter 
a  mutually  binding  agreement  to  begin  exchanging 
EDI  transaction  sets.  The  recital  should  state  that 
the  parties  intend  to  be  legally  bound  in  the  same 
manner  as  though  they  were  exchanging  hard-copy 
paper  documents. 

•  Standards.  The  TPA  should  specify  all  standards 
and  their  issuing  organizations;  it  should  reference 
data  dictionaries,  segment  dictionaries,  etc.;  and  it 
should  state  how  to  handle  updates  of  newly 
adopted  standards.  (DoD  has  adopted  the 
ANSI  X12  standards  developed  by  the  ASC  X12.) 
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•  Documents.  The  TPA  should  specify  which 
transaction  sets  are  authorized  to  be  exchanged 
between  the  parties.  The  TPA  is  a  good  place  to 
incorporate  by  reference  the  industry  guidelines 
that  will  be  followed.  Most  DoD  procurement, 
financial,  and  shipping  documents  can  be 
transmitted  using  the  standard  EDI  transactions, 
segments,  and  data  elements. 

•  Duration.  The  TPA  should  specify  the  effective  date 
and  period  the  TPA  is  to  be  in  effect.  Execution 
requirements  and  any  necessary  approvals  should 
also  be  stipulated. 

•  Communications  mode  for  EDI.  DoD  may  require 
that  the  Federal  Government  file  transfer  system, 
or  FTS-2000,  be  used.  If  approval  is  obtained  to  use 
an  independent  communications  provider,  the  TPA 
should  specify  the  name  of  the  provider,  the  method 
of  payment  for  services,  and  the  notification  or 
procedure  required  to  change  the  provider. 

•  Acknowledgments/acceptances.  The  TPA  should 
include  the  legal  requirements  for  any  special 
acknowledgments  or  acceptances  as  a  condition  for 
the  transaction  to  be  legal.  If  you  require 
remittance  advice,  for  example,  specify  it  here. 

•  Disputes.  Small  businesses  may  follow  state  law  in 
disputes,  but  DoD  contracts  will  contain  the 
standard  disputes  clause  specified  in  FAR  52-233. 

•  References.  You  may  incorporate  any  special 
publications,  specifications,  and  guidelines  by 
reference.  You  should  specify  the  order  of  priority 
in  case  of  internal  conflicts  in  references. 

•  Security.  You  should  agree  upon  and  specify 
security  procedures  to  be  followed  by  each  party  to 
protect  business  data  from  improper  access  and/or 
disclosure. 
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•  Signatures.  To  provide  for  the  confidentiality  of  the 
signatures  of  both  authorizing  parties,  the  TPA 
should  establish  a  method,  such  as  a  discrete 
authentication  code,  that  can  be  affixed  in  code  or  in 
symbol  to  each  transaction  set. 

•  Mailbox  contents.  The  TPA  should  specify  at  what 
time  each  day  the  parties  are  required  to  review  and 
collect  the  contents  of  their  mailboxes.  Ordering  or 
shipping  requirements  may  also  be  specified. 

•  Force  majeure.  The  TPA  should  include  a  typical 
act  of  God  clause  excepting  such  things  as 
explosion,  fire,  or  flood  from  imposing  a  liability  on 
either  party. 

•  Garbled/erroneous  transmissions.  The  TPA  should 
allocate  the  risks  of  garbled  or  erroneous 
transmissions  as  negotiated.  It  should  specify  who 
shall  be  liable,  if  anyone,  for  bad  transmissions.  If  a 
third-party  provider  is  responsible,  the  extent  of  the 
liability  must  be  set  out  clearly. 

•  Termination.  If  the  agreement  may  be  terminated 
by  either  party,  the  TTA  should  state  this  fact.  It 
should  specify  the  termination  notification  period. 
It  should  also  set  the  parameters  and  termination 
procedures  to  be  followed  if  one  of  the  parties  falls 
below  an  acceptable  standard  of  performance. 

•  Damages.  The  TPA  should  describe  how  the  parties 
should  handle  special  or  consequential  damages,  as 
well  as  actual  or  liquidated  damages. 

•  Whole  agreement.  The  TPA  should  contain  the 
t3rpical  clause  covering  mergers. 

•  Special  terms  and  conditions.  You  may  add  any 
other  special  provisions  that  may  be  wise  and 
necessary  to  establish  an  efficient  trading 
operation. 
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The  Electronic  Messaging  Services  Task  Force,  a 
Subcommittee  on  Electronic  Commercial  Practices, 
Uniform  Commercial  Code  Committee,  Section  of 
Business  Law,  American  Bar  Association,  has 
prepared  a  draft  model  agreement  to  assist  the 
practitioner  in  preparing  a  TPA. 


THIRD-PARTY  SERVICE  AGREEMENTS 

The  small  business  can  choose  from  a  host  of 
commercial  value-added  network  services  (also  called 
third-party  services). 

Third-party  providers  can  be  of  great  service  in  getting 
any  EDI  program  off  to  a  good,  solid  start.  They  can 
provide  a  variety  of  services,  especially  to  small, 
unsophisticated  trading  partners  not  conversant  with 
the  technology.  They  can  assist  in  selecting  hardware 
and  software  and  in  providing  training. 

Usually  third-party  service  providers  have  their  own 
printed  contract  forms  which  will  be  helpful  to  the 
small  business. 

Like  any  legal  agreement,  the  third-party  agreement 
should  not  be  drafted  and  executed  without  the 
assistance  of  competent  legal  advice.  The  merger  or 
whole  agreement  clause  is  a  necessity  as  well  as  the 
force  majeure  clause,  which  exonerates  the  provider 
from  liability  connected  with  acts  of  God,  such  as  fire, 
theft,  and  other  causes  outside  the  control  of  the 
service  provider.  In  addition,  the  small  business 
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should  negotiate  acceptable  terms  in  these  areas 
because  of  the  following  concerns: 


•  There  should  be  a  complete  description  of  the 
services  to  be  provided  to  the  respective  trading 
partners. 

•  There  should  be  language  specifying  that  the  third- 
party  provider  has  no  independent  property  interest 
in  the  data  and  further,  foreclosing  any  claim  that 
the  provider  has  added  value  to  the  data  giving 
some  legal  right  to  a  mechanic’s  lien  or  a  possessory 
lien. 

•  There  must  be  an  understanding  that  the  provider 
will  store  records  or  perform  some  archival  service 
should  be  covered  along  with  the  cost  for  this 
service.  If  you  desire  backup  copies,  this  agreement 
should  provide  for  them.  It  should  also  specify  the 
length  of  time  backup  copies  must  be  kept. 

•  The  confidentiality,  integrity,  and  security 
measures  to  be  provided  should  be  listed  in  the 
third-party  agreement. 

•  The  third-party  provider’s  responsibility  for 
accurate,  reliable  service  should  be  outlined.  You 
should  define  the  third  party’s  liability  and  its 
scope;  responsibility  for  compensatory  damages  in 
case  of  data  loss,  delay,  mistakes,  or  misdirection; 
liquidated  damages;  etc. 

•  The  agreement  termination  date  should  be 
outlined.  The  agreement  should  say  whether  the 
date  can  be  changed  periodically  and  whether  the 
parties  are  free  to  change  service  providers  after  the 
date  has  been  agreed  upon.  This  is  the  time  and 
place  to  specify  these  issues.  Agree  upon  a  standard 
of  services  below  which  the  parties  may  terminate 
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the  agreement  without  risk  of  breach  and 
associated  damages. 

•  Very  definite  language  should  be  included  detailing 
exactly  how  the  network  charges,  if  any,  will  be 
shared  between  the  suppliers  and  the  customers. 
DoD  may  be  able  to  negotiate  a  no-cost,  service- 
provided  agreement  with  a  network. 

•  Include  a  warranty  that  the  provider’s  system, 
when  used  in  consonance  with  procedures  specified, 
will  perform  as  stated.  This  should  not  mean  the 
provider  has  absolute  liability  but  that  the  provider 
should  deliver  services  as  promised  barring 
extraordinary  circumstances.  Inclusion  of  a 
provision  that  this  warranty  is  in  lieu  of  any 
warranties  implied  by  law  is  a  reasonable 
requirement. 

•  Outline  the  network  requirements  to  support  ANSI 
or  EDI  for  administration,  commerce,  and  transport 
(EDIFACT)  standards.  Specify  the  small  business 
expectations.  What  audit  trails  are  to  be  provided? 

•  You  should  specify  all  record  keeping  requirements. 
For  example,  when  can  the  provider  discard  the 
data?  The  provider  may  ask  for  a  short  statute  of 
limitations  beyond  which  its  liability  is  forgiven. 
DoD  cannot  agree  to  such  a  provision  because  it 
must  use  the  statutory  period  provided  by  Federal 
law. 
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BACK-UP  PROCEDURES 


Businesses,  large  and  small,  should  establish  back-up 
recovery  procedures  so  they  can  retransmit  unsuccess¬ 
ful  EDI  messages.  The  following  safeguards  should 
prove  useful. 

•  Back-up  procedures  should  be  available  for  use  if 
the  computer  system  or  communications  fail. 

•  Establish  a  maximum  number  of  attempts  at 
retransmission  after  a  transmission  error  to 
minimize  comraunitations  costs. 

•  Establish  a  minimum  back-up  of  24  to  48  hours  of 
data.  You  will  need  access  to  this  much  data  for 
real-time  transactions,  such  as  the  advance  ship 
notice  and  shipping  schedule. 

•  Batch  transactions,  such  as  those  used  for  the 
purchase  order  and  invoice,  require  a  1-  to  2-week 
back-up. 

•  Some  types  of  data  must  be  archived  on  a  more 
permanent  basis.  Ideally,  this  should  be  accom¬ 
plished  at  a  different  location.  The  permanent 
archives  and  supporting  system  should  allow  a 
specific  EDI  message  to  be  recovered. 


The  back-up  and  recovery  system  must  be  thoroughly 
documented.  It  should  allow  anyone  with  the  proper 
authority  to  retransmit  data. 


The  functional  acknowledgment  (transaction  997)  can 
be  used  to  provide  a  level  of  automation  for  backup  and 
recovery.  If  the  EDI  system  is  designed  to  receive  a 
functional  acknowledgment  for  every  transaction 
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group  it  sends,  that  group  should  be  available  for 
retransmission  until  the  sender  receives  a  functional 
acknowledgment.  Once  the  sender  receives  that 
functional  acknowledgment,  the  system  can  archive 
the  original  EDI  message. 

The  system  should  be  designed  to  provide  a  degree 
flexibility.  The  use  of  functional  acknowledgments 
can  vary  based  on  business  requirements.  It  may  be 
appropriate  to  send/receive  functional  acknowl¬ 
edgments  to  some  and  not  other  trading  partners,  for  a 
specific  transaction  or  combination  of  the  two,  or 
for  some  other  variation  unique  to  your  EDI 
requirements. 

DoD  will  require  functional  acknowledgments. 

Recovery  Procedure  Considerations 

You  should  establish  recovery  procedures  to  provide 
controlled  management  of  unusual  telecommunica¬ 
tions  problems  such  as  the  following: 

•  A  trading  partner’s  computer  or  VAN  will  not 
respond  when  your  computer  calls  to  pick  up  or 
deliver  EDI  messages. 

•  A  bad  connection  causes  continuous  or  excessive 
numbers  of  retransmissions. 
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Disaster  Recovery  Considerations 


Disaster  recovery  becomes  correspondingly  critical  as 
the  number  of  EDI  transactions  increases.  Consider 
the  consequences  if  you  were  suddenly  unable  to  send 
messages  for  an  unacceptably  long  period. 

You  should  not  assume  that  you  can  fall  back  on  a 
paper-based  system.  Your  trading  partners  may  not 
be  able  to  switch  from  EDI  back  to  paper.  You  may  not 
have  access  to  the  resources  needed  for  paper 
transactions. 

Develop  a  plan  to  deal  with  extreme  problems,  such  as 
a  total  loss  of  your  data  center,  computer  system,  or 
telecommunications.  If  you  use  a  microcomputer, 
backup  may  be  as  simple  as  using  an  alternate  PC  and 
software.  The  larger  your  system,  the  more  complex 
your  solution  will  have  to  be. 


SECURITY 


The  elimination  of  paper  document  processing  through 
the  introduction  of  ANSI  X12  EDI  standards  requires 
an  evaluation  of  your  existing  internal  control 
processes  and  procedures.  Without  a  signed  document 
and  paper  audit  trail,  you  still  must  determine 
whether  a  transaction  is  accurate,  valid,  and  approved. 


The  small  business  should  make  certain  that  security 
precautions  taken  to  protect  EDI  data  and 
transmission  are  at  least  as  good  as  those  currently 
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used  for  the  paper  exchange.  The  small  business  at  a 
minimum  should  adhere  to  the  standards  developed  by 
its  trading  partner. 

This  problem  is  not  new.  All  software  and  telecom¬ 
munications  systems  have  addressed  this  problem  for 
years.  The  same  elements  of  control  apply  to  EDI  as 
they  do  to  other  automated  systems.  Controls  must 
ensure: 

•  Confidentiality  —  only  authorized  persons  have 
access  to  data. 

•  Integrity  —  data  accuracy. 

•  Authenticity  —  proof  of  valid  transaction  and 
ownership. 

POINTS  OF  CONTACT 

If  you  would  like  additional  information  about  the 
SBA’s  training  schedules,  call  the  Division  of  Minority 
Small  Business  Outreach  at  (202)  205-6421.  If  you 
have  questions  about  participating  in  a  DoD  EDI 
program,  call  the  DoD  Executive  Agent  for  Elec¬ 
tronic  Commerce/Electronic  Data  Interchange  at 
(703)617-7107. 
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GLOSSARY 


ACH 

Automated  Clearing  House 
ANSI 

American  National  Standards  Institute 
ANSI  standard 

A  document  published  by  ANSI  that  has  been 
approved  through  the  consensus  process  of  public 
announcement  and  review.  Each  of  these  standards 
must  have  been  developed  by  an  ANSI  committee  and 
must  be  revisited  by  that  committee  within  5  years  for 
update. 

Application  acknowledgment 
A  transaction  set  whose  purpose  is  to  return  a  response 
to  a  transaction  set  that  has  been  received  and 
processed  in  an  application  program.  The  purchase 
order  acknowledgment  (transaction  855)  is  an  example 
of  an  application  acknowledgment.  It  is  used  to 
respond  to  the  purchase  order  (transaction  850) 
presenting  such  things  as  whether  the  receiver  can 
fulfill  the  order  and  if  it  can  be  done  on  time. 

Application  advice  (824) 

A  transaction  set  that  documents  errors  in  the  content 
of  any  transaction  set  beyond  the  normal  syntax 
checks 

ASC 

Accredited  Standards  Committee 
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ASC  X12 

The  Accredited  Standards  Committee  X12  comprises 
Government  and  industry  members  who  create  EDI 
draft  standards  for  submission  to  ANSI  for  subsequent 
approval  and  dissemination. 

Authentication 

A  mechanism  which  allows  the  receiver  of  an 
electronic  transmission  to  verify  the  sender  and  the 
integrity  of  the  content  of  the  transmission  through 
the  use  of  an  electronic  key  or  algorithm  which  is 
shared  by  the  trading  partners.  This  is  sometimes 
referred  to  as  an  electronic  signature. 

Compliance  checking 
A  checking  process  that  is  used  to  ensure  that  a 
transmission  complies  with  ANSI  X12  syntax  rules 

Conditional  (C) 

A  data  element  requirement  designator  which 
indicates  that  the  presence  of  a  specified  data  element 
is  dependent  on  the  value  or  presence  of  other  data 
elements  in  the  segment.  The  condition  must  be  stated 
and  must  be  computer  processable. 

Control  segment 

A  control  segment  has  the  same  structure  as  a  data 
segment  but  is  used  for  transferring  control 
information  for  grouping  data  segments. 

Control  validation 

Provides  confirmation  that  information  within  the 
control  segments  is  correct 

Data  element 

The  basic  units  of  information  in  the  EDI  standards 
containing  a  set  of  values  that  represents  a  singular 


fact.  They  may  be  single-character  codes,  literal 
descriptions,  or  numeric  values. 

Data  element  length 

This  is  the  range,  minimum  to  maximum,  of  the 
number  of  character  positions  available  to  represent 
the  value  of  a  data  element.  A  data  element  may  be  of 
variable  length  ranging  from  minimum  to  maximum, 
or  it  may  be  of  fixed  length  in  which  the  minimum  is 
equal  to  the  maximum. 

Data  element  reference  number 

The  reference  number  assigned  to  each  data  element 

as  a  unique  identifier 

Data  element  requirement  designator 
A  code  defining  the  need  for  a  data  element  value  to 
appear  in  the  segment  if  the  segment  is  transmitted. 
The  codes  are  mandatory  (M),  optional  (0),  or 
conditional  (C). 

Data  element  separator 

A  unique  character  preceding  each  data  element  that 
is  used  to  delimit  data  elements  within  a  segment 

Data  element  type 

A  data  element  may  be  one  of  six  types:  numeric, 
decimal,  identifier,  string,  date,  or  time. 

Data  Interchange  Standards  Association 
The  Secretariat  and  administrative  arm  of  ASC  X12 

Delimiters 

These  consist  of  two  levels  of  separators  and  a 
terminator.  The  delimiters  are  an  integral  part  of  the 
transferred  data  stream.  Delimiters  are  specified  in 
the  interchange  header  and  may  not  be  used  in  a  data 
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element  value  elsewhere  in  the  interchange.  From 
highest  to  lowest  level,  the  separators  and  terminator 
are  segment  terminator,  data  element  separator,  and 
subelement  separator  (only  used  in  EDIFACT). 

Direct  transmission 

The  exchange  of  data  from  the  computer  of  the  sending 
party  directly  to  the  computer  of  the  receiving  party. 

A  third-party  value-added  service  is  not  used  in  a 
direct  transmission  code. 

EC 

electronic  commerce 

EDI 

electronic  data  interchange 
EDIA 

Electronic  Data  Interchange  Association.  A  nonprofit, 
public  interest  organization  designed  to  develop, 
foster,  and  maintain  a  program  of  action  to  achieve 
coordination  of  data  and  information  systems  by  the 
standardization  of  descriptions  and  codes  for 
intercompany  computer-to-computer  EDI  for  business 
transactions. 

EDIFACT 

This  is  an  international  standard  for  EDI  for 
administration,  commerce,  and  transport. 

EDI  translation 

The  conversion  of  application  data  to  and  from  the  X12 
standard  format 

EDI  translator 

The  computer  software  used  to  perform  the  conversion 
of  application  data  to  and  from  the  X12  standard 


EFT 

electronic  funds  transfer 
E-mail 

electronic  mail 
Electronic  mailbox 

The  place  where  an  EDI  transmission  is  stored  for 
pickup  or  delivery  within  a  third-party-service 
provider’s  system.  Trading  partners  can  also  maintain 
mailboxes  within  their  own  domains. 

Encryption 

A  process  of  transforming  clear  text  (data  in  its 
original  form)  into  ciphertext  (encr3^tion  output  of  a 
cryptographic  algorithm)  for  security  or  privacy 
(security  transaction  set  815) 

ERS 

evaluated  receipt  settlement 

FAR 

Federal  Acquisition  Regulation 
FMS 

Financial  Management  Service 

FRB 

Federal  Reserve  Bank 

Functional  acknowledgment 
A  transaction  set  (997)  transmitted  by  the  receiver  of 
an  EDI  transmission  to  the  sender,  indicating  receipt 
and  syntactical  acceptability  of  data  transmitted 
according  to  the  ASC  X12  standards.  The  functional 
acknowledgment  allows  the  receiving  party  to  report 
back  to  the  sending  party  problems  encountered  by  the 
syntax  analyzer  as  the  data  are  interpreted.  It  is  not 
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intended  to  serve  as  an  acknowledgment  of  data 
content. 

Functional  group 

A  group  of  one  or  more  transaction  sets  bounded  by  a 
functional  group  header  segment  and  a  functional 
group  trailer  segment 

Industry  conventions 

This  defines  how  the  ASC  X12  standards  are  used  by 
the  specific  industry. 

Industry  guidelines 

This  defines  the  EDI  environment  for  using 
conventions  within  an  industry.  It  provides  assistance 
on  how  to  implement  XI 2  standards. 

IOC 

initial  operational  capability 
Mandatory  (M) 

A  designator  that  indicates  a  specified  data  element  is 
required 

Mapping 

The  process  of  identifying  the  relationship  of  the 
standard  data  elements  to  application  software  data 
elements 

Message 

The  entire  data  stream  including  the  outer  envelope 
NTE 

note  segment  —  EDI  message 


Optional  (O) 

A  data  element/segment  requirement  designator  that 
indicates  the  use  of  the  element  is  at  the  option  of  the 
sending  party 

PC 

personal  computer 
Proprietary  format 

A  data  format  specific  to  a  company,  industry,  or  other 
limited  group.  Proprietary  formats  do  not  comply  with 
ASC  X12  standards. 

RFQs 

requests  for  quotes 
SBA 

Small  Business  Administration 
Security 

A  process  of  system  screening  that  denies  access  to 
unauthorized  users  and  protects  data  from 
unauthorized  uses 

SF 

Standard  Form 
Syntax 

The  grammar  or  rules  which  define  the  structure  of 
the  EDI  standards 

TDCC 

Transportation  Data  Coordinating  Committee 
TPA 

trading  partner  agreement 
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Trading  partner 

The  sending  and/or  receiving  party  involved  in  the 
exchange  of  EDI  transmissions 

Transaction  set 

The  transaction  set  unambiguously  defines,  in  the 
standard  syntax,  information  of  business  or  strategic 
significance.  It  consists  of  a  transaction  set  header 
segment,  one  or  more  data  segments  in  a  specified 
order,  and  a  transaction  set  trailer  segment. 

Transaction  set  ID 

A  code  that  uniquely  identifies  the  transaction  set. 
This  identifier  is  the  first  data  element  of  the 
transaction  set  header  segment. 

Translation 

The  act  of  accepting  documents  in  other  than  standard 
format  and  translating  them  to  the  standard 

VAN 

value-added  network.  These  are  usually  third-party 
service  organizations. 


